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Abstract 


This paper proposes and analyzes modifications to the Land- 
mark routing system that make it better suited to large ad hoc 
wireless networks. Most existing ad hoc routing algorithms 
scale badly in the sense that they generate protocol overhead 
whose per-node cost grows linearly with the total number of 
nodes. The Landmark routing protocol solves this problem 
by use of hierarchical addresses that contain routing hints; 
as a result, however, a node’s address changes as the net- 
work topology changes. The Landmark system tracks node 
addresses with a distributed I[D-to-address location service, 
but queries to this service require communication with ran- 
dom non-local nodes, which scales badly in large networks. 

The main contribution of this paper is a set of modifi- 
cations to the Landmark address lookup service to make it 
more scalable. The paper also improves the Landmark hier- 
archy maintenance and routing algorithms to help them react 
better to mobile nodes. Finally, it presents a simulation eval- 
uation of the resulting system, L*, from the point of view of 
scalability in wireless ad hoc networks. The evaluation shows 
that the per-node bandwidth requirement of L*+ grows very 
slowly as the number of nodes in the network increases. This 
is consistent with our analysis that the per-node communica- 
tion cost of Lt is O(log N). 


1 Introduction 


This paper addresses the problem of scalable routing in large 
ad hoc wireless networks of mobile nodes. Such networks are 
of interest because they do not rely on fixed infrastructure. 
As a result these networks can support a number of promis- 
ing new technologies such as ubiquitous computing [24], sen- 
sor networks, rooftop networks [1, 19], and wireless PDAs. 
A major obstacle to the use of large ad hoc networks is the 
lack of an adequately scalable routing system. This paper de- 
scribes and analyzes modifications to the Landmark routing 
system [22, 21, 23] to make it suitable for large ad hoc wire- 


less networks. 

An important way in which wireless ad hoc networks dif- 
fer from wired networks, and wireless networks with wired 
backbones, is that they are likely to have severely constrained 
capacities. Each node’s radio is likely to have the same capac- 
ity; an engineered high-capacity wireless backbone is likely 
to be awkward in many ad hoc scenarios. More fundamen- 
tally, the nodes are embedded on a plane, with connectivity 
only to nearby nodes. Assuming uniform node density, the 
expected distance between a random pair of nodes is O( VN) 
in both physical distance and number of hops, where JN is the 
total number of nodes; similarly, the cross section bandwidth 
of the network is also O(N). This means that if commu- 
nication patterns tend to be long-distance, or even random, 
the average amount of traffic that any one node can origi- 
nate scales as ir [7, 12]. That is, the more nodes there are, 
the less long-distance traffic any one node can originate. This 
holds true even if the area of the universe (and thus the degree 
of spectrum re-use) scales with the number of nodes. 

As a consequence of this capacity constraint, the domi- 
nant traffic patterns in large ad hoc networks will probably 
need to be local [12]; this would allow each node to origi- 
nate an amount of traffic independent of the total size of the 
system. However, it is not enough that the traffic pattern be lo- 
cal: the per-node overhead generated by the routing protocol 
must also grow slowly with total network size. One conse- 
quence of this is that, ideally, the per-node routing overhead 
should be a constant independent of the size of the system. 
More practically, the per-node overhead should be a slowly 
growing function of the system size, such as O(log N). For 
example, this rules out standard distance-vector, which has a 
per-node communication cost of O(V). For reactive proto- 
cols, which query for routes to destinations only as needed, 
capacity constraints suggest that queries should travel a dis- 
tance proportional to the distance between the nodes desiring 
to communicate; otherwise local communication will gener- 
ate global routing traffic, which won’t scale well. 

Few existing ad hoc routing protocols conform to the re- 
strictions described above. For example, DSDV [17] uses a 


distance-vector algorithm that imposes O(V) per-node com- 
munication cost, where N is the number of nodes in the net- 
work, while DSR [4] and AODV [18] flood queries globally 
even for local communication. As a consequence, we should 
expect these protocols’ overhead to exhaust node radio capac- 
ities relatively quickly as networks grow larger. In practice, 
the situation is not this simple. If the network topology does 
not change, these protocol’s overheads can be made arbitrar- 
ily small. Even if the topology changes, DSR and AODV have 
caching and local re-query mechanisms that limit the cost of 
finding and repairing routes. Still, the overall scaling argu- 
ment suggests that these protocols might work badly in very 
large ad hoc networks. Section 5 shows that this is true. 

More scalable ad hoc routing protocols do exist. For ex- 
ample, the combination of geographic forwarding and the 
GLS location service [13] provides a routing system that 
scales as O(log N’). However, both geographic forwarding 
and GLS require that nodes know their geographic locations, 
perhaps using the Global Positioning System (GPS). This de- 
pendence is likely to be impractical for many uses of ad hoc 
networks. 

Landmark routing is a potentially scalable protocol that 
does not depend on GPS. Instead of using geographic loca- 
tions as addresses, Landmark addresses nodes using their po- 
sitions in a dynamically maintained hierarchy. Landmark ad- 
dresses effectively encode an abbreviated route in the form of 
a path down the hierarchy. These addresses allow packets to 
be routed with very little per-node state, and thus little per- 
node routing overhead. Landmark limits the number of nodes 
in the network that any one node knows about to O(log NV). 
Thus the per-node routing overhead is O(log N’). However, 
since a node’s address may change when the network topol- 
ogy changes, the complete Landmark system includes a dis- 
tributed database that maps each node’s permanent ID to its 
current address. Queries to this database require global com- 
munication; thus the complete Landmark system as originally 
described is not likely to scale well in large ad hoc networks. 

This paper introduces L*, a modified Landmark routing 
system designed for large ad hoc mobile networks. L* differs 
from Landmark mainly in its location service. Unlike Land- 
mark, the number of hops each Lt location query takes is 
proportional to the distance between the sender and the re- 
ceiver. Hence, L* avoids global communication when the 
underlying traffic pattern is local. The location update traf- 
fic in L* also follows the power-law distribution, making 
it mostly local. Finally, L* modifies the Landmark hierar- 
chy maintenance and routing algorithms to make them react 
better to mobility. In Section 5 we use simulations to show 
that L* scales well; the per-node bandwidth requirement of 
L* grows very slowly as the number of nodes in the network 
increases. This result is consistent with our analysis that the 
per-node communication cost of an L* node is O(log N). In 
addition, L* scales better than original Landmark, particu- 
larly for local communication patterns. 


The rest of the paper is structured as follows. Section 2 
describes the original Landmark routing system. Section 3 
describes the L* location service. Section 4 describes the 
hierarchy maintenance and routing algorithms used in LT. 
Section 5 analyzes performance of L*, and compares it with 
Landmark and DSR. Section 6 discusses related work. Fi- 
nally, Section 7 concludes. 


2 Landmark Overview 


This section reviews the original design of Landmark rout- 
ing [21, 22, 23]. Landmark is a distributed routing protocol 
designed for large networks with loose administrative do- 
mains and changing topology. Landmark creates and main- 
tains a hierarchy of nodes that reflects network topology. A 
node’s address is its position in the hierarchy. Routing based 
on these addresses requires very little state; each node need 
only know its own parent (to forward up towards the root) 
and its own children (to forward down towards the leaves). It 
is the limited size of the per-node state, and correspondingly 
limited state update communication, that allows Landmark 
routing to scale to large network sizes. 

Each Landmark node has a unique, unchanging identi- 
fier (ID); this might be, for example, an IP address. In ad- 
dition, each Landmark node has an address, which changes. 
The Landmark system includes a distributed location service 
to map from IDs to addresses. 


2.1 Landmark Hierarchy 


The Landmark hierarchy is a tree of nodes, called landmarks. 
By convention, the leaves are called level 0 landmarks. Ev- 
ery node starts out as a level 0 landmark. Each level / land- 
mark picks a level /+1 landmark within a radius of r; hops 
as its parent. If no level /+1 landmark exists within 7; hops, 
the node participates in an election to choose a new level 
(+1 landmark. This means that roughly one node in each area 
of radius of r; becomes a level 7 landmark. Eventually, one 
node becomes the root landmark of the entire hierarchy. 

The radius at level 0, 79, is 2 network hops. It doubles ev- 
ery level, so 7; = 2r;_1. Consequently, the radius of the area 
covered by the top level landmark, at level H, is O(2/). As 
a result, the number of landmark levels needed for a network 
is O(log N), where N is the number of nodes in the network. 

Landmarks learn about each other by running a modified 
distance-vector (DV) routing protocol. Each landmark places 
a limit on the number of hops that its information propagates 
in the DV protocol; this limit is 27; for a level | landmark. 
This radius is the advertisement distance. Consequently, the 
number of nodes that know about a particular landmark in- 
creases as the level of that landmark increases. Francis [21] 
shows that even though the number of landmarks elected at 
each level />0 grows as O(N), the number of landmarks a 
node knows about at each level />0 stays at a constant value 
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Figure 1: Example of a Landmark hierarchy. Node a is a level 
0 landmark. Node 0 is a level 1 landmark, within radius ro of 
a. Node cis a level 2 landmark, within radius r; of b. Node a’s 
address is a.b.c. The two dotted curves represents the adver- 
tisement boundary from b and a. A packet that d addresses to 
a.b.c is forwarded along the path represented by the sequence 
of arrows. 


until the total number of landmarks elected in the network at 
that level drops below the constant. Thus, the total number of 
landmarks each node knows about is O(log N). 

As the network topology changes, the number of hops 
between a node and its parent may increase to the point 
where the node must choose a new parent. Similarly, topol- 
ogy changes may require new landmarks to be elected, or old 
ones to be demoted. A level / landmark increments its land- 
mark level when there are no other /+1 landmarks that can 
cover all the level / landmarks in the vicinity. Similarly, a 
level / (1 > 0) landmark decrements its level when all the 
level /—1 landmarks in the vicinity can be covered by another 
level J landmark. 

Figure 1 shows an example of a simple hierarchy. In this 
figure, node a is a level 0 landmark. Node 0 is a level 1 land- 
mark, within 79 radius from a. Node c is a level 2 landmark, 
within r; radius from b. Node d, far away from a, knows 
about the root landmark c, but not b or a. 


2.2 Landmark Routing 


A node’s Landmark address is composed of the node’s ID, 
followed by its parent’s ID, then the ID of the parent’s parent, 
and so on, and eventually the root landmark’s ID. For exam- 
ple, the address of node a in Figure 1 is a.b.c. 

When a node receives a packet that it must forward, it 
looks for each component of the destination address in its 
own DV routing table. It will certainly find a routing table 
entry for the root landmark. As the packet moves towards the 
destination, or even towards the root, forwarding nodes are 
also likely to find other address components in their routing 
tables. A forwarding node uses the routing table entry cor- 


responding to the left-most (lowest level) known component 
in the address. It forwards the packet to the next-hop node 
indicated by that entry. 

A landmark may not forward a packet even if it is one 
of the components in the destination address of the packet. 
It is very likely that before the packet reaches this landmark, 
it was redirected toward another landmark to the left of this 
landmark in the destination address. For example, in Figure 
1, when node d sends a packet to a, the packet moves along 
the path formed by the arrows. d first sends the packet toward 
c. When a forwarding node less than 27; hops (i.e. adver- 
tisement distance of b, represented by the dotted curve) from 
b receives the packet, it forwards the packet to b. Similarly, 
when a forwarding node less than 2r9 hops from c receives 
the packet, it forwards the packet to c. 

Landmark routing does not typically forward a packet 
using the shortest path. Often when a source node sends a 
packet, the packet moves toward a higher level landmark be- 
fore being redirected toward the destination. [21] provides de- 
tailed analysis in terms of path length increase as the size of 
the network grows. 

It would be undesirable if a packet had to get within a few 
hops of one of the address components before it could start 
to be forwarded to the next more-specific component. This 
would cause, for example, the nodes around the root land- 
mark to experience heavy forwarding load. This turns out not 
to be the case. Suppose that a packet is moving towards a 
level J landmark that is 2r; away (the full length of the level 
1 advertisement distance). This packet can be redirected to- 
wards a level /—1 landmark as soon as it is within the ad- 
vertisement range of the level /—1 landmark, 27;_;. Because 
the level /—1 landmark is at most r;_; away from the level / 
landmark, at the point where redirection occurs, the packet is 
still, in the best case 
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hops away from the level / landmark. Therefore, all nodes 
that are within + - 2r; hops away from a level / landmark can 
be used to redirect packets to level /—1 landmarks. Since a 
packet will be redirected as soon as it enters this area, nodes 
on the perimeter of this area assume the role of the level | 
landmark. This implies that the load of the root landmark is 
spread among O(N) nodes. 


2.3 Landmark Location Service 


One of the difficulties of Landmark routing is that Land- 
mark addresses change as the topology changes. To solve this 
problem, Landmark provides an ID-to-address location ser- 
vice that works as follows. A node picks its location server 
by taking the hash of its own ID, and uses the hash result 
as the Landmark address of its location server. Every time a 
node’s address changes, the node sends a location update to 


its location server. When a sender wants to send a packet to 
a receiver, the sender computes the Landmark address of the 
receiver’s location server by taking the hash of the receiver’s 
ID. 

A problem with this approach is that the hash of a node’s 
ID would most likely not map into a usable Landmark ad- 
dress. To solve this problem, a hashed address is resolved into 
areal Landmark address level by level. A node sends the loca- 
tion update or query packet towards the root of the hierarchy 
first. When the node forwarding this packet is close enough to 
the root that it knows about all the root landmark’s immediate 
children, it forwards the packet towards the child whose ID is 
closest to the hashed address. This process continues at each 
level until the packet is forwarded to a level 0 landmark. This 
level 0 landmark is the desired location server. 

This mechanism for choosing a node’s location server has 
the following good properties. It distributes the work of stor- 
ing locations evenly across the nodes in the network. It allows 
any node to find a target node’s location server, and thus the 
target node’s address, given only the target node’s ID. Finally, 
if a node’s location server moves or fails, everybody automat- 
ically agrees on how to find a new location server. 


3. The L* Location Service 


The Landmark location service does not scale well to large 
ad hoc wireless networks because its location update and 
query traffic is global. For every location update or query, a 
node must send a packet to a server chosen among all of the 
nodes in the network. This means on average, a location query 
packet travels O(N ) hops, even if the two nodes that want 
to communicate are close to each other. Landmark lookups 
effectively turn scalable local communication patterns into 
unscalable global patterns. 

L* provides a location service that scales well if the com- 
munication pattern is local. An L* node sends location up- 
dates to more than one location server. The location servers 
are chosen such that the expected distance to each server is 
exponentially farther away from the node. When a node per- 
forms a location query for a destination, with a high probabil- 
ity, L* resolves the query using a nearby location server. 


3.1 Server Selection 


At each level / of the hierarchy, a node sends an update 
to a level J landmark it knows of (in its DV routing ta- 
bles) whose hashed ID is numerically closest to the node’s 
hashed ID, hash(id). It chooses this landmark using the 
choose-landmark (id,/) procedure call. Pseudo code for 
the procedure is shown in Figure 2. This level / landmark 
then sends the update downward in the hierarchy, just as in 
the original Landmark location server mechanism, to its level 
!—1 child with hashed ID closest to hash (7d). It obtains this 
child by calling the choose-child procedure. For example, 


choose-landmark(id, level) 
selected = —1 
closest = 0 
for each landmark / in DV table 
if (J.level == level) 
d= abs(hash(l.id)-hash(7d)) 
if (d < closest or selected == —1) 
closest = d 
selected = l.id 
return selected 


choose-child(id, parent, level) 


selected = —1 
closest = 0 
for each landmark / in DV table 
if (J.level == level and |.parent == parent) 
d= abs(hash(l.id)-hash(7d)) 
if (d < closest or selected == —1) 


closest = d 
selected = l.id 
return selected 


Figure 2: Procedures used when resolving the hash of 
an ID into a real Landmark address. Each node uses the 
choose-landmark procedure to select a landmark at each 
level to send location update or query to. Each landmark, sub- 
sequently, uses the choose-child to propagate the update or 
query downward in the hierarchy. 


when a level 2 landmark a receives an update that needs to 
be propagated downward, it calls choose-child(id,a, 1) 
to select one of its level | children. If this procedure returns 
the level 1 landmark 6, the update is then sent to b. b, or a 
node near b, calls choose-child(id,b,0) to select the final 
location server. 

An update or query sent to a level / landmark a does not 
need to reach a. A forwarding node close to a can start push- 
ing the update or query downward in the hierarchy (i.e. call- 
ing choose-child(id,a,/+1)) if it has all the children of 
a in its DV table. This is always the case if the forwarding 
node is 7;_1 hops away from a: every child of a is at most 
rj—1 hops away from a, and each of those children has an 
advertisement distance of 27;_1 hops. 

When a node a wants to look up the current address 
of a destination whose ID is 8, it first sends a query to 
the level 1 landmark it knows of whose hashed ID is 
closest to hash(b). This landmark, obtained by calling 
choose-landmark (b, 1), then sends the query downward in 
the hierarchy to its level 0 child with hashed ID closest to 
hash(b). If that child doesn’t know about 8, a tries again at 
level 2, and so forth. 

The intuition behind this scheme comes from the obser- 
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Figure 3: Updating and querying L* location servers. Each node appears as hash(ID) , level in the picture. Solid lines repre- 
sent location updates. Dotted lines represent location queries. Circled nodes are intermediate nodes in the address resolution 
process. Boxed nodes are the final location servers. Circled or boxed nodes with the same shade are part of the same resolution 


process. The example is explained in Section 3.2. 


vation that the number of landmarks two nodes both see de- 
pends on the distance between these two nodes. If they are 
very close to each other, they may see the same set of level 
1 landmarks. If they are slightly farther apart, they may see 
different level 1 landmarks, but the same set of level 2 land- 
marks. The closer the two nodes are, the more likely that calls 
to choose-landmark would return the same result at lower 
levels of the hierarchy. Thus nodes that are close physically 
can look up each others’ addresses with local query commu- 
nication. 


3.2 Updating and Querying Location Servers 


When a node’s Landmark address changes, it only sends up- 
dates to a subset of its location servers, in a way that en- 
sures local motion usually generates local update traffic. If the 
Landmark address changes starting at the level | component, 
an update is sent to the landmark at level /+1. Each update 
contains a timeout which is proportional to the expected in- 
terval between sending updates to that level of the hierarchy. 
In addition, nodes send location updates at a slow rate propor- 
tional to r; to landmarks at each level, even when stationary. 
The frequency at which the address of node a changes 
depends on the frequency at which a changes its parent and 
the frequency at which other components in the address of a 
change their parents. A level / landmark picks a new parent 
when its old parent is more than r; hops away. Hence, the 
frequency at which the level /+1 component of an address 
changes depends on the mobility rate relative to r;. Therefore, 
components of an address that correspond to the low levels of 
the hierarchy may change relatively often. On the other hand 
the higher level components of the address will change less 
frequently. Because low-level changes generate local updates, 
the location update traffic follows a power law pattern. 
Sending updates less frequently to distant servers implies 
that the addresses stored at distant servers may become stale. 


Therefore, instead of answering a query directly, each loca- 
tion server forwards the query towards the destination using 
the address stored in the location database. If the address is 
stale, a node near the old location may still have the node in 
its DV table. A query with a stale address can also be incre- 
mentally refined to obtain a correct address. 

The refining process works as follows. Assume node a 
sends a query for destination b very far away. Consider that 
one of a’s queries reaches a location server that has an old 
address for b. The query is forwarded to b’s old location in 
the hierarchy. When a forwarding node can no longer forward 
the query using the stale address, it may choose to refine the 
query. If forwarding failed because the level —1 component 
of the address cannot be reached, the forwarding node sends a 
location query for 6 starting at level /+-1. The intuition is that 
the node has not moved too far away from its old location, 
and therefore consulting a nearby location server is likely to 
produce the correct address. Furthermore, if the address broke 
at level /—1, that means it is likely that the level /—1 landmark 
changed its parent. In that case, an update would have been 
sent to a level /+-1 server. 

Figure 3 shows an example of how updating and query- 
ing L* location servers work. Each node in the network 
appears as hash(ID),level in the picture. Solid lines 
represent location updates. Dotted lines represent location 
queries. Circled nodes are intermediate nodes in the ad- 
dress resolution process. Boxed nodes are the final loca- 
tion servers. Circled or boxed nodes with the same shade 
are part of the same resolution process. In a), node 13 
selects three landmarks to send location updates to using 
choose-landmark (13,1), choose-landmark(13,2),and 
choose-landmark (13,3). The three chosen landmarks are 
16, 15, and 41 respectively. Each of these landmarks for- 
wards the location update by using the choose-child pro- 
cedure. For example, when node 15 receives the update, it 


calls choose-child(13, 15, 1), which returns node 11. 
The update is then sent to node 11. Node 11 then calls 
choose-child(13, 11, 0), which returns 29. 29 is the fi- 
nal location server. In b), node 13 moves and acquires a new 
address 13.16.23.41. Since the level 1 component of the 
address changed, it sends an update to the level 2 landmark 
computed using choose-landmark(13,2). In this case it 
is still node 15. The location update eventually reaches lo- 
cation server 29. In the meantime, node 33 sends a query 
for 13 through the root landmark 41. The query is resolved 
via 14 first, then 10. Location server 19 finally forwards 
the query to 13’s old location, 13.9.15.41. Node 9, how- 
ever, can no longer forward to 13. In c), because forwarding 
failed at level 0, node 9 selects a level 2 landmark by call- 
ing choose-landmark(13, 2). The query is sent to node 15 
again. It eventually reaches location server 29. 29 forwards 
the query to node 13. Finally, 13 answers the query using the 
source address in the query packet. 


3.3 Scalability of L* 


This section considers the expected per-node bandwidth re- 
quirements of an L* node in a static network with local com- 
munication. 

Four items contribute to the per-node bandwidth. First, 
the DV protocol used for Landmark hierarchy mainte- 
nance and routing. Francis [21] shows that this overhead 
is O(log N). Second, each L* location update packet con- 
tributes to the per-node bandwidth of every node on its for- 
warding path. Because a node sends location updates expo- 
nentially less often to far away location servers, the Lt lo- 
cation update traffic pattern follows the power-law distribu- 
tion. Hence, the per-node overhead from forwarding location 
updates is O(log N). Third, forwarding a L* location query 
packet also contributes to per-node bandwidth. If communi- 
cation is local, then with high probability L* uses a nearby 
location server to resolve each query. Thus the overhead of 
forwarding location queries is O(1). Fourth, the local com- 
munication pattern contributes an overhead of O(1) to the 
per-node bandwidth. Adding them together, the expected per- 
node bandwidth of an L* node in a static network with local 
communication grows as O(log N) in the worst case. 

In original Landmark, the expected per-node bandwidth 
requirement in a static network with local communication 
pattern can be dominated by the need to send location updates 
and queries to random nodes, imposing a O( VN ) per-node 
communication costs in the worst case. 

Mobility complicates the analysis of the overhead of for- 
warding location queries, since queries to nearby location 
servers may fail. If the probability is high that a query for 
a nearby destination can be resolved by a nearby server, then 
the per-node bandwidth remains O(log N) in the worst case. 


4 Handling Mobility in L* 


This section describes several changes L* makes to the hier- 
archy and routing algorithms of the original Landmark sys- 
tem. These modifications make L* react better to mobility. 
In our simulations, we used a Landmark implementation with 
these changes. 

Similar to Landmark, L* uses a distance vector algorithm 
to distribute information about landmarks. Each node peri- 
odically advertises its own information (i.e. node ID, land- 
mark level, advertisement radius, how many potential parents 
it has, a chosen parent, and a secondary parent) in addition 
to the nodes in its routing table. A routing table entry is only 
advertised if the distance to the node is less than the node’s 
advertised advertisement distance. Most nodes have an ad- 
vertisement distance of 27; where / is the node’s Landmark 
level. The root landmark and landmarks with the three high- 
est IDs in the second highest level are designated as global 
landmarks and have advertisement radii of infinity. 


4.1 Building the Hierarchy 


If a node with Landmark level / cannot find a level /+-1 par- 
ent within 7; hops, it considers incrementing its Landmark 
level to /+-1. To prevent several nodes within r; of each other 
from incrementing their Landmark levels at the same time, a 
node scans its routing table first. It increments its Landmark 
level only if it has the highest ID among all eligible nodes 
(i.e. nodes that advertise 0 as the number of potential parents) 
within 77. 

This election algorithm tends to promote just one land- 
mark in each area that needs one. A disadvantage of the algo- 
rithm is that it may promote higher level landmarks slowly, 
since a node must wait long enough that news of a distant 
high-level landmark’s promotion would reach it before it can 
promote itself. 

With mobility, a level / landmark may move into a region 
and discover that all landmarks of level /—1 in this region 
have parents already. In L*, a level 1 landmark decrements 
its Landmark level to |—1 if it sees that every level /—1 land- 
marks within 7;_; hops away has at least 2 potential parents. 
Using 2 instead of | provides both redundancy and stability, 
as other level | landmarks could be moving away. A node 
does not decrement its Landmark level if it sees that it will no 
longer have a parent after doing so. 

Unlike Landmark, Lt does not require explicit registra- 
tion between parent and children. A level / landmark can pick 
any level /+1 landmark within r; hops as its parent. In prac- 
tice, to reduce the number of address changes, a node picks 
the nearest landmark among its potential parents. Addition- 
ally, each node also picks the second nearest landmark among 
its potential parents as a secondary parent. If there is only one 
potential parent, the secondary parent is the same as the par- 
ent. 


Because the advertisement radius of a level / landmark is 
2r; hops, and every level /—1 landmark must have a level / 
parent within r; hops, a node sees DV updates from all of its 
ancestors. Consequently, a node can compose its own Land- 
mark address from its routing table. 

A node composes two Landmark addresses for itself. The 
first address is composed using the node’s parent, node’s par- 
ent’s parent, etc. The second address is composed using the 
node’s secondary parent, the secondary parent’s secondary 
parent, etc. In most cases, the two addresses differ at multiple 
components. To make routing work better, each node sends 
location updates with both addresses. An address lookup also 
returns both addresses, and every data packet is tagged with 
both addresses as well. 


4.2 Moving Location Database Entries 


A change in the Landmark hierarchy may change how a 
node’s hashed ID maps to the nodes that act as its location 
servers, even if it doesn’t change the node’s address. If noth- 
ing special were done, it might take a long time before the 
node updated its new location servers. To address this prob- 
lem, each Lt node periodically scans the location entries it 
stores, looking for entries that should be stored by one of the 
other children of its parent. It forwards such entries to the 
relevant child. 


4.3 Routing in L* 


The distance vector algorithm used by L* is similar to 
DSDV [17]. It differs from DSDV in that L*+ keeps more than 
just the shortest route to each destination. If the shortest dis- 
tance to a destination is determined to be d hops, L* keeps 
a list of routes with distance d hops or d + 1 hops. If d is in 
fact the shortest route, then a route with a distance of d+ 1 
hops cannot contain a loop, since each loop causes at least 
2 additional hops. The distance advertised for a destination 
is the distance of the first route in the route list. Keeping a 
list of routes instead of one route allows a node to use alter- 
nate routes when the shortest route breaks. To prevent loops, 
trigger update is used to propagate the metric change, if any, 
when the shortest route on the route list is removed either due 
to timeout or MAC transmit feedback (i.e. transmit to the next 
hop indicated in this route failed). 

Packet forwarding in L* works as follows. When a node 
receives a packet that it must forward, it looks for each com- 
ponent of the destination address in its own routing table. A 
forwarding node uses the routing table entry corresponding 
to the left-most (lowest level) known component in the ad- 
dress. A routing failure occurs if the packet has previously 
reached the left-most known component in the address, or if 
no known component exists. We switch to the second des- 
tination address if a routing failure occurred using the first 
destination address. We drop the packet if a routing failure 


occurred using the second address. 


5 Simulation Results 


This section presents results from a L* implementation in the 
ns-2 [14] network simulator, using 802.11 as the MAC. It 
first shows that routing in Lt, with a perfect location service, 
scales well. Then, using a static network and local commu- 
nication pattern, we isolate the overhead of location queries. 
Finally, we demonstrate the scalability of L* in two poten- 
tial styles of deployment: a mobile ad hoc network where 
all nodes are moving, and a rooftop wireless network where 
routers are stationary but clients of the network move. For 
comparison, results are also shown for DSR [4] and for the 
original Landmark system augmented with the routing and 
hierarchy maintenance mechanisms described in Section 4. 

Our goal is to show that per-node communication require- 
ments in L* grow slowly with the total number of nodes. In 
order to be able to observe the amount of per-node bandwidth 
required to support large networks, we effectively eliminated 
the capacity limit of the simulated 802.11 radios (by setting 
the capacity to 100 Mbps rather than 2 Mbps). The actual 
bandwidth recorded is the sum of transmit and receive band- 
width values in each 1-second interval, counting only suc- 
cessfully received packets. The bandwidth results show both 
the median and 99th percentile values of all 1-second mea- 
surements over all nodes. The 99th percentile gives an indi- 
cation of how fast node radios would have to be in order to 
avoid congestion at the vast majority of nodes. 

In our simulations, the radio range is 250 meters. Un- 
less otherwise noted, each scenario starts out with an aver- 
age node density of 10 nodes per radio range. We increase 
the area of the network accordingly as the number of nodes 
increases. Mobile nodes follow the random waypoint model 
with no pause time: initially, each node chooses a destina- 
tion uniformly at random in the simulated region, chooses a 
speed uniformly at random between 0 and 10 m/s, and moves 
there with the chosen speed. Upon arrival, the node immedi- 
ate picks another destination and speed and repeats the same 
process. 

Unless otherwise stated, the simulated communication 
pattern is as follows. Each node in the system sends traffic 
to one other randomly selected node; the selection is done in 
a way that ensures that no node receives traffic from more 
than two other nodes. Each node sends a total of 15 128-byte 
packets at a rate of 3 packets per second. Each simulation 
lasts 1,200 seconds. The start time of each of these flows is 
randomly chosen over the last 400 seconds of each simula- 
tion. This allows the hierarchy to be constructed in the first 
800 seconds of the simulation (most do not take nearly this 
long). 

The DSR code in ns was modified to have a maximum 
route request length of 32 hops instead of the default 16 hops; 
this allows DSR to reliably find paths in the larger simula- 
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Figure 4: Per-node bandwidth of Lt routing with a perfect lo- 
cation service. The dotted line represents 99th percentile val- 
ues; the solid line represents median values. 


tions. 

In the bandwidth graphs presented below, the dotted lines 
represent 99th percentile per-node bandwidth values, and the 
solid lines represent median values. Unless otherwise noted, 
each point represents results from just one simulation run. 
(We will fix this; we believe that lack of multiple runs doesn’t 
affect the results much because node mobility causes constant 
change in the topology.) 


5.1 Scalable Routing 


Figure 4 shows the bandwidth required to route packets using 
L* as a function of the number of nodes in the network. The 
simulations in this graph operated with no location service: 
each node magically knows the current correct address of the 
node it is sending data to. Since the location service is not 
in use, DV routing updates make up most of the traffic. The 
shape of the required bandwidth curve can be explained by 
the fact that, in a Landmark hierarchy, the number of desti- 
nations advertised in each DV update is O(log N) [21]. Our 
simulation reports the same relationship between the number 
of Landmarks in each node’s DV table and the number of 
nodes in the network. 

The slow growth of the 99th percentile shows that no node 
or small set of nodes acts as a bottleneck; in particular, it is 
not the case that many packets have to be routed through the 
root of the hierarchy or the nodes immediately surrounding it. 

Figure 5 compares per packet hop count between L* rout- 
ing and shortest path routing. Shortest path routing was ap- 
proximated using geographic forwarding with a perfect loca- 
tion service; the reason for not computing the actual shortest 
path is that it is not well defined, since nodes move while 
packets are in transit. The approximation is that each node 
forwards a packet through the neighbor geographically clos- 
est to the destination. The graph shows that Lt uses routes 
that are a few tens of percent longer than shortest path. 
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Figure 5: The percentage by which L* routes are longer than 


geographic shortest paths, as a function of total number of 
nodes in the network. 
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Figure 6: Per-node bandwidth as the number of nodes in- 
creases, for a lattice network with a local communication pat- 
tern. All packets were delivered without loss. The per-node 
cost of L+ grows slowly compared to that of original Land- 
mark. 


5.2 L* Location Query Performance 


Results in this section demonstrate how the query traffic gen- 
erated by L* scales with network size, for a local communi- 
cation pattern. Simulations in this section run in a static lat- 
tice network, where nodes are 150 meters apart. The local 
communication pattern is produced by each node choosing 
a destination between 1000 and 1400 meters away, out of a 
universe size of 3000 m? at 400 nodes to 6700 m? at 2000 
nodes. 

Figure 6 shows that the per-node communication cost of 
L* grows slowly compared to that of original Landmark, for 
local traffic. The results are consistent with the observation in 
Section 3.3 that Landmark scaling can be dominated by the 
need to send location updates and queries to random nodes, 
imposing O( VN ) per-node communication costs. L* sends 
local queries for local communication, which would scale as 


45 T T T T | 


Lt —— 
40 - Landmark —e— J 


Average query length 
Po 
o 
1 


0 1 i i i i 
400 800 1200 1600 2000 


Number of nodes 


Figure 7: Average query length, in hops, as the number of 
nodes increases. The communication pattern is local; the 
number of hops between each source and destination pair is 
between 5 and 10 hops. Query length includes hop counts 
from failed queries as well as from successful queries. 


Table 1: Average intervals, in seconds, between updates that 
L* nodes send through various landmark levels. These follow 
a power law distribution, helping L* avoid non-scalable long- 
distance communication. 


O(1); however, it sends location updates to each level of the 
hierarchy at power-of-two intervals and has a O(log N) DV 
routing overhead, thus its per-node communication cost is 
O(log N). 

Figure 7 illustrates the difference between L+ and Land- 
mark query traffic by showing query length in hops. Again, 
the fact that L* generates local queries for local communica- 
tion means that its query lengths grow more slowly than those 
of Landmark. 


5.3. Mobile Network Simulations 


This section demonstrates that L*+ scales well in networks 
of mobile nodes. Experiments in this section use a random 
communication pattern, rather than the local pattern of the 
previous section. 

Figure 8 shows that as the network size increases, the per- 
node bandwidth increases slowly under L* and Landmark. 
In contrast, per-node bandwidth increases linearly with DSR. 
The linear increase is caused by DSR flooding queries over 
the whole network, sometimes multiple times per connection 
as cached routes break due to node mobility. 

L* and Landmark behave similarly in the mobile net- 
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Figure 8: Per node bandwidth as the number of nodes in- 
creases, for mobile nodes. Dotted lines represent 99th per- 
centiles; solid lines represent median values. Per-node band- 
widths for L* and Landmark routing grow slowly as the num- 
ber of nodes increases. In comparison, per-node bandwidth 
for DSR grows linearly. 
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Figure 9: Query success rate as the number of nodes in- 
creases drops slightly under both L* and Landmark. 


work. One reason is that the communication pattern is ran- 
dom, so the Lt location service only benefits a small fraction 
of lookups. Another reason is that nodes following a random 
waypoint movement model tend to cluster near the center of 
the network. The high density at the center causes the DV 
broadcast packets to be large; these packets dominate per- 
node bandwidth, masking the savings from the L* location 
service. 

Table 1 shows how often each node sends out location 
updates under L*. Recall that in addition to periodic location 
updates, a node also sends location updates when it detects 
a change in its Landmark address. If the change occurred at 
the level / component of the address, the update is resolved 
through a level /+1 landmark. Table 1 confirms our belief that 
with this update scheme the update traffic follows a power- 
law distribution, since higher level components of a Land- 
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Figure 10: Fraction of packets delivered as the number of 
nodes increases. Both L+ and Landmark routing deliver a 
high fraction of the packets as the number of nodes increases. 
Almost all the packet losses occur due to failed location 
queries. In comparison, DSR drops packets due to broken 
routes very early on. 


mark address are less likely to change with mobility. 

Figure 9 shows that as the network size increases, the 
query success rate drops. Instability in the Landmark hierar- 
chy (i.e. parent changes, nodes electing themselves to be land- 
marks, and nodes removing themselves as landmarks) cause 
most of the query failures. Hierarchy instability also increases 
location update frequencies. Figure 10 shows the fraction of 
data packets delivered; the fraction is high for L*+ and Land- 
mark. The reason for the packet losses with DSR is that DSR 
is vulnerable to broken source routes due to mobility. 


5.4 Rooftop Network Simulations 


This section evaluates the performance of L* in a simulated 
rooftop network environment. The rooftop network contains 
both static and mobile nodes. The static nodes are laid out in 
a lattice formation with 150 meters between adjacent nodes. 
Only the static nodes participate in the Landmark hierarchy, 
and only the static nodes forward packets. The mobile nodes 
act as sources and sinks of data, but do not forward, partici- 
pate in the Landmark hierarchy, or appear in the DSDV up- 
dates. The mobile nodes do send location updates and queries 
as described in Section 3. The Landmark address of a client is 
simply the Landmark address of the landmark closest to the 
client. When a landmark receives a packet with its address as 
the destination address, but with a different destination ID, 
it tries to send the packet to that node directly. If the trans- 
mit fails because the node has moved away, either the sec- 
ond Landmark address on the packet is used, or the packet is 
dropped. 

In the following simulations, static nodes do not initi- 
ate data flows themselves. Communication between mobile 
nodes follows a local model: each sender sends packets to a 
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Figure 11: Per node bandwidth as the number of mobile 
clients increases for a rooftop network. The number of clients 
and number of Landmarks are the same. Landmarks are po- 
sitioned in a static grid. 


-. —— -—__.. £_- — sh] 
ae) an | 
2 = 
o & & “4 
= 0.98 + 5 
(0) 
me) 

n 
@ 0.96 + 4 
[S) 
© 
a 
%5 «(0.94 F 4 
Cc 
Bo) Lt —— 
S 0.92 F Landmark —e— 7 
ic DSR —s— 
400 800 1200 1600 2000 


Number of clients 


Figure 12: Fraction of packets delivered as the number of 
clients increases for a rooftop network. Landmarks are posi- 
tioned in a static grid. 


receiver between 800 and 1200 meters away at the time the 
communication starts. In each scenario there are equal num- 
ber of static and mobile nodes. The density of mobile nodes 
is 10 nodes per radio range. The x-axis of each graph reflects 
the number of mobile nodes in the network. 

Figure 11 shows that as the network size increases, the 
per-node bandwidth requirements of L+ grow slowly. Its 
growth rate is consistent with the observation in Section 3.3 
that Lt has a per-node communication cost that is O(log N). 
L* scales slightly better than original Landmark, and sub- 
stantially better than DSR. Again, DSR bandwidth require- 
ments grow linearly due to global flooding of queries when 
source routes break due to mobility. The DSR curve starts to 
flatten after 1200 nodes because the implementation’s maxi- 
mum source route length is 32 hops, too small for the longest 
required paths in networks with 1600 and 2000 nodes. We 
were not able to run large simulations with higher maximum 
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Figure 13: Per node bandwidth in an 800-node L* rooftop 
network as the average interval between successive node fail- 
ure increases. Each node failure involves a randomly selected 
node dying for 120 seconds. 


source route lengths due to memory constraints. 

Figure 12 shows the packet delivery rates of L*+, Land- 
mark, and DSR as the number of nodes increases. The de- 
livery rates for all three protocols remain high even as the 
network size increases. DSR does not drop too many packets 
even though it has bad required bandwidth scaling because we 
are using 100 Mbps radios in these simulations. Both L* and 
Landmark have better deliver rate in rooftop networks than in 
mobile networks because the Landmark hierarchy, and thus 
the location service infrastructure, is fixed. Most packet drops 
by L* and Landmark, however, are still triggered by failed 
location queries. 

If a client is moving away from the landmark that it had 
picked as a parent, it must wait until that landmark’s informa- 
tion expires from its DV table before picking a new parent. If 
a client is moving slowly, there is a good chance that at least 
one of the two Landmark addresses it picked is current. How- 
ever, if a client is moving quickly, it cannot pick new parents 
fast enough. This contributes to most of the query failures 
in the Landmark and Lt simulations. This problem may be 
fixed by using a smaller timeout value for expiring entries 
from the DV table, or by using a more sensitive metric for 
picking parents, such as signal strength. With varying link 
conditions, however, these techniques may trigger unneces- 
sary address changes. 

Sometimes a sender in L* selects the wrong server to use 
at lower levels of the hierarchy. If the location servers corre- 
sponding to higher levels of the hierarchy contain stale ad- 
dresses, Lt counts on query refinement to forward the query 
to the destination. When a client is moving fast, query refine- 
ment does not work well: the node performing the query re- 
finement and the client may obtain different results when they 
call choose-landmark. This contributes to the extra packet 
drops by L*. 

Figures 13 and 14 show the effect of node failures on the 
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Figure 14: L* query success rate in an 800-node rooftop net- 
work as the average interval between successive node fail- 
ure increases. Each node failure involves a randomly selected 
node dying for 120 seconds. 


performance of L* in a rooftop network of 800 mobile and 
800 static nodes. We model a node failure by turning off a 
randomly selected node for 120 seconds. Each node failure 
occurs at a randomly chosen time during the part of the sim- 
ulation that involves communication (i.e. last 400 seconds). 
When a failed node turns back on, all entries in its DV table 
and most of the entries in its location database have expired. 
Unexpired entries contain stale addresses. 

Figure 13 shows that as the frequency of node fail- 
ure decreases, per-node bandwidth requirements decrease as 
well. When node failure is frequent, the hierarchy constantly 
changes, triggering large numbers of location updates. Fig- 
ure 14 shows that as the frequency of node failure decreases, 
the query success rate increases. When node failure is fre- 
quent, hierarchy changes cause rapid changes in location 
server selection. These data show that L* can handle unstable 
nodes gracefully. 


6 Related Work 


Geographic Forwarding [5, 9, 13, 3] is the only other rout- 
ing protocol we know of that scales well in large wireless 
ad hoc networks. In geographic forwarding, a node forwards 
a packet through the neighbor geographically closest to the 
packet’s destination. Each node only needs to know the posi- 
tions of its immediate neighbors; so the communication and 
storage costs scale as O(1). Geographic forwarding, however, 
requires each node to know its geographic location, perhaps 
using the Global Positioning System (GPS); this is gener- 
ally not convenient. Landmark and L* routing aren’t quite 
as scalable as geographic forwarding; they have O(log NV) 
costs. On the other hand, their use of a dynamically chosen 
hierarchy is likely to be more practical than dependence on 
GPS. 


Geographic forwarding scales well, but requires that end- 
points of conversations find each others’ current geographic 
location. how a node acquires the geographic position of a 
destination. DREAM [2] nodes pro-actively flood position 
updates over the whole network, allowing other nodes to build 
complete position databases. LAR [10] nodes reactively flood 
position queries over the entire network when they wish to 
find the position of a destination. Both of these systems in- 
volve global flooding, making them best suited to small net- 
works. 

GLS is a scalable location service intended to track des- 
tination node positions in ad hoc networks using geographic 
forwarding [13]. Each node chooses its location servers from 
nodes positioned at exponentially increasing distances. Loca- 
tion updates use a scalable communication pattern that fol- 
lows the power law [12]: frequency of updates lowers ex- 
ponentially as the distance to the location server increases. 
Location queries mimic the actual communication pattern: 
queries for nearby nodes are answered by nearby location 
servers; whereas queries for distant nodes are answered by 
distant location servers. Landmark routing has an organi- 
zation similar to that of GLS: both use a location service 
combined with a routing system that locations as addresses. 
Again, GLS (as well as geographic forwarding) depends on 
nodes having GPS receivers, or some equivalent. L* has sim- 
ilarly high scalability, but is self-contained, with no depen- 
dence on anything like GPS. 

LANMAR [6] assumes that nodes move in_pre- 
determined groups, embeds a group number in each node’s 
address, and runs an inter-group routing protocol as well as an 
intra-group protocol per group. This means that the amount of 
routing state per node is related to the number of groups plus 
the number of nodes in one group, rather than the total num- 
ber of nodes. This scheme achieves good scaling in applica- 
tions with natural group structure, but may not scale if nodes 
move predominantly as individuals instead of in groups. 

A number of existing ad hoc routing algorithms make 
use of globally-distributed topology information. For exam- 
ple, AODV [18], DSR [4], DSDV [17], and TORA [15] flood 
routing queries or complete routing advertisements to the en- 
tire network. Route caching and local repair reduce the impact 
of this flooding, but there is a significant O(V) per-node cost 
in these algorithms that does not scale well. 

The Zone Routing Protocol (ZRP) [8] finds paths to nodes 
by globally flooding queries, but ensures that only one node 
in any given zone needs to process each query. A zone is de- 
fined as as certain radius of hops. Nodes accumulate a list of 
all the nodes in their zone using a limited-radius pro-active 
routing protocol, and use that list to answer queries. The 
global query flooding suggests that ZRP might have a O(V) 
per-node communication cost component, which might scale 
badly in large networks. 

Fisheye State Routing (FSR) [16] and Fuzzy Sighted Link 
State (FSLS) [20] are two protocols designed to scale to large 


networks by reducing the frequency and size of topology up- 
dates. Every node learns the topology of the entire network. In 
FSR, routing table entries are propagated with progressively 
decreasing frequency as the distances to these nodes increase. 
In FSLS, a node aggregates link changes and propagates them 
at frequencies that depend on how far the link changes oc- 
curred from itself. Nodes still need to keep a quantity of state 
that scales with the total size of the network, and that state 
may become stale if nodes move quickly; these factors may 
limit these algorithms ability to handle very large networks. 

SCOUT [11] uses the Landmark hierarchy as a clustering 
technique for sensor networks. Each landmark propagates a 
summary of the objects its child sensors are monitoring. A 
remote sensor uses this summary to redirect queries to sensors 
with more detailed information about a particular object, until 
the query reaches the most relevant sensor. 


7 Conclusion 


This paper introduces Lt, a modified Landmark routing sys- 
tem designed for large ad hoc mobile networks. L* differs 
from Landmark mainly in its location service. Unlike Land- 
mark, the number of hops each L* location query takes cor- 
responds with the distance between the sender and the re- 
ceiver. Hence, L* avoids global communication when the 
underlying traffic pattern is local. The location update traf- 
fic in Lt also follows the power-law distribution, making it 
mostly local. Finally, L+ modifies the Landmark hierarchy 
maintenance and routing algorithms to make them react bet- 
ter to mobility. Simulation results show that the per-node re- 
quired bandwidth of L+ grows slower than both Landmark 
and DSR. The results are consistent with our analysis that the 
per-node communication cost of L*+ is O(log N). 
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